View figure.
This section introduces Data Link Switching (DLSw) and summarizes the DLSw function implemented in Network Utility.
DLSw is an IBM-invented standard technology for transporting connection-oriented protocols, mainly SNA and NetBIOS, across IP backbone networks. DLSw routers on the edges of an IP network field link establishment requests from native SNA and NetBIOS end stations, search among peer DLSw routers for one serving the target end station, and then set up a path and relay application data between the end stations through the peer router.
The protocol that flows between DLSw routers is documented in RFC 1795, "Data Link Switching: Switch to Switch Protocol." Clarifications about this protocol and multicast IP-based scalability enhancements are documented in RFC 2166, "DLSw v2.0 Enhancements".
Many DLSw implementations provide a local DLSw function that connects two links within a single router, as opposed to connecting them across an IP network to another DLSw router. Depending on the DLC types involved, this function may be equivalent to that of a FRAD or X.25 PAD.
The Network Utility DLSw implementation is nearly identical in function to that of the IBM 2210 and 2216 routers. It can handle the following end-station protocols:
Network Utility DLSw can communicate with end stations across the following data link control (DLC) types:
LLC can be carried over any of these interface types:
DLSw can represent the primary station on a multipoint line, multiple secondary stations, or a single fully negotiable station on a point-to-point line.
DLSw supports any combination of QLLC PVCs and SVCs on a single X.25 interface. It can handle parallel virtual circuits to the same remote DTE address, as well as incoming calls from non-configured SVCs.
You can configure APPN to attach to the DLSw function residing in the same Network Utility. This allows APPN to have links with any PU 2.0 or T2.1 SNA end station in the DLSw network, without requiring APPN to be present in remote (especially branch office) routers.
DLSw supports an internal interface to the ESCON and parallel channel LSA function residing in the same Network Utility. This allow the host to have links with any SNA end station in the DLSw network, without requiring separate channel gateway and central-site DLSw router products.
With remote DLSw (across IP to another router), Network Utility DLSw supports conversion from TCP DLSw frames to any of the supported DLC types. Local DLSw is supported only for specific combinations of DLC types, as shown here:
LLC SDLC QLLC APPN Channel-LSA
LLC (1) x x x
SDLC x x x x x
QLLC x x x x x
APPN x x x
CHANNEL x x x x
Note:
1 - You should use bridging for local LLC-to-LLC connectivity. The
only exception supported by local DLSW is LLC to a Frame Relay
bridge port that is configured as a Boundary Access Node (BAN) port.
The following list summarizes some of the other capabilities and features of IBM Network Utility DLSw.
IBM DLSw supports RFC 1434+, RFC 1795 (DLSw Version 1), and RFC 2166 (DLSw Version 2). It dynamically detects the protocol level of each partner router with no pre-configuration, and can simultaneously handle partners at different protocol levels.
IBM DLSw supports bringing up TCP connections to configured partners only when required, as well as discovering end stations served by non-configured partners, and bringing up those TCP connections on demand.
With the simple configuration of multicast IP addresses or groups, IBM DLSw can perform multicast searches for both end stations and partners. IBM DLSw provides a number of dynamic extensions to the DLSw Version 2 standard, including resource registration and simplified group configuration.
There are configuration options allowing you to control not only SNA versus NetBIOS prioritization, but also individual circuit priorities. This is in addition to the Bandwidth Reservation System's (BRS) extensive support for interface-level traffic prioritization.
IBM DLSw includes extensive support for MAC address and NetBIOS name lists and static caching, allowing you to control what links are used for searching for resources as well as which remote partners are preferred.
IBM DLSw can cache multiple remote partners and select among them on the basis of neighbor priority, largest frame size support, or first to reply. You can also use the neighbor priority feature to ensure that one central-site router serves only as a backup for another.
For configurations involving duplicate MAC addresses, you can disable the neighbor priority feature, or set cache parameters to control the paths used to reach those MAC addresses.
This section describes three sample configurations that use the Data Link Switching feature of the Network Utility. These configurations are:
This scenario is shown in Figure 16-1. In this scenario, the SNA traffic in the remote sites uses DLSw to get back to the data center.
The Network Utility is in the data center on the backbone LAN segment. It is a DLSw partner with each remote router and as such requires a TCP session with each. The advantage to this approach is that all of the CPU cycles needed to manage these TCP sessions and to terminate the DLSw connections are concentrated in the Network Utility. Without the Network Utility, the local routers or the host gateway (if DLSw-capable) could be consumed by this workload.
From the host perspective, the SNA LLC2 traffic is bridged into the Network Utility from the host gateway. The host gateway is either an IBM 3745/46, an IBM 3746 with the Multiaccess Enclosure (MAE), or an IBM 2216.
You can take advantage of the 2-Port Token-Ring Adapter in the Network Utility by bringing in the IP-encapsulated SNA traffic on one port and delivering LLC2 SNA traffic onto the other Token-Ring port. Thus, you have twice the bandwidth available with an additional benefit of separating the IP and SNA traffic onto separate rings. Because the Network Utility provides LLC local acknowledgments (spoofing) to the host for each LLC connection, this removes a considerable amount of traffic from the campus backbone in large network environments.
Figure 16-1. DLSw LAN Catcher
View figure.
For the most part, this is a standard DLSw configuration. However, you should be aware of the following points when configuring the Network Utility as a DLSw LAN Catcher:
This option completely disables forwarding of explorer frames.
If you want to block explorer frames from going out on WAN links, then you can specify this option. This is the default value for the Network Utility.
With this option, explorer frames are sent out to all DLSw partners.
For a complete look at the configuration parameters needed for the DLSw LAN Catcher scenario, see Table 17-2.
This scenario is shown in Figure 16-2. As in the DLSw LAN catcher scenario, the Network Utility terminates the DLSw sessions from the remote routers. However, in this case, there is an ESCON Channel Adapter in the Network Utility. Instead of bridging the traffic from the DLSw function onto the LAN segment, this configuration passes it directly to the channel via an LSA loopback interface configured in the Network Utility.
This configuration also demonstrates the use of the Network Utility to support SNA traffic from the local campus to the host. This traffic is bridged off the campus backbone through the LSA loopback interface. All SNA devices in the network are configured with the same host destination MAC address which is the MAC address of the LSA loopback interface. This includes the devices at the main site as well as the devices in the remote sites.
Figure 16-2. DLSw LAN Channel Gateway
View figure.
| Note: | This example illustrates the use of the Network Utility as a channel gateway for DLSw traffic only. However, many of the functions illustrated in the Channel Gateway example configurations on page "Example Configurations" could be combined with DLSw termination in a valid channel gateway configuration. |
Note the following points when configuring the Network Utility as a DLSw LAN Channel Gateway:
| Note: | You can also define an LSA direct connection for the traffic to be bridged in from the local LAN segments. If you do this, then the devices on these segments will have a different destination MAC address from the remote devices because the LSA direct interface will have a different MAC address from the LSA loopback interface. |
This scenario is shown in Figure 16-3. It uses Local DLSw in the Network Utility to map between X.25 addresses and MAC address/SAP pairs. The transport across the WAN is native Qualified Logical Link Control (QLLC), a protocol that allows SNA devices to communicate over X.25 networks. In the Network Utility, local DLSw performs protocol conversion between QLLC and LLC2 frames.
From the remote device perspective, there are two cases to consider:
On the workstation, the SNA application generates an LLC frame that it wants to send to the host. If the branch router is an IBM 2210, this LLC frame gets bridged into the 2210 DLSw function, which does three things:
The X.25 PAD function in the branch router creates the LAPB link layer packets and sends them over the PVC (or SVC).
If some product other than the IBM 2210 plays the role of branch router, it needs to perform these same functions but may do so without using local DLSw.
On these devices, SNA uses QLLC as a native DLC type. It generates a QLLC frame and sends it out over the configured PVC (or SVC).
In each of these cases, at the Network Utility, the LAPB packets are received over the X.25 circuit and passed to QLLC and then on to DLSw. DLSw does two things:
The traffic is then passed to the LSA loopback interface for transport across the ESCON channel.
Figure 16-3. DLSw X.25 Channel Gateway
View figure.
The following list summarizes general configuration tasks you need to perform for this scenario. Please refer to other DLSw and LSA loopback configurations for details. The LSA loopback interface is configured the same as in DLSw LAN Channel Gateway.
In addition to these general tasks, you need to configure Network Utility DLSw to map X.25 addresses to the LSA loopback MAC address. There are three ways to do this:
The remainder of this section describes how to configure each of these three address mapping methods.
If the number of remote X.25 stations is relatively small, then you can configure each remote X.25 device in DLSw to be mapped to the LSA loopback MAC address. To do this using the command line, enter talk 6 at the * prompt and type the following:
To do this using the Configuration Program, do the following:
If your remote X.25 stations can be configured to send a connection ID when they place a call21, you can configure DLSw to map connection ID values to destination MAC addresses. To do this using the command line, enter talk 6 at the * prompt and type the following:
To do this using the Configuration Program, do the following:
Finally, if it is not feasible to configure each remote X.25 station or to use a connection ID, you can use the DLSw ANYCALL feature to accept any incoming X.25 call and map it to the LSA loopback MAC address. To do this using the command line, enter talk 6 at the * prompt and type the following:
To do this using the configuration tool, do the following:
This section introduces some of the ways in which you can monitor and manage the DLSw function.
DLSw supports an extensive set of commands to display status, dynamically modify configuration parameters, and actively control the state of connections. These commands are described in detail in MAS Protocol Configuration and Monitoring Reference Volume 1, in the chapter "Configuring and Monitoring DLSw." To access them, enter talk 5 at the * prompt and protocol dls at the + prompt.
Some particularly useful commands for monitoring status are:
If you configure a "local TCP connection" to enable local DLSw function, this connection is flagged as such on the command output so that it can be distinguished from remote partner connections.
Because a Network Utility may easily have hundreds or thousands of active sessions, you can use different variations of the list dls session command to display only a subset of them. Instead of the keyword "all," you use different keywords to show only those circuits through a given partner, or only those in a given state, and so on. There are roughly 10 keywords defined to select sessions. The output of all these commands pauses when the screen fills, waiting for a keystroke from you to continue or quit. Press the space bar to view the next screen of output.
DLSw supports dynamic modification under talk 5 of the vast majority of parameters you can configure under talk 6. DLSw follows the standard model where changes made under talk 5 have an immediate effect but do not survive a box reboot, while changes made under talk 6 take effect only after a box reboot. The talk 5 list commands show the values that are currently active in the running product.
The talk 5 commands delete and disable give you the power to tear down an existing DLSw connection. For example, you can use delete dls session number to clean up a hung session and allow the end stations to redrive it. Delete/add and disable/enable sequences are powerful methods to recycle configured TCP, SDLC, and QLLC connections.
DLSw has several hundred ELS messages defined, ranging from informational messages about normal events, to warnings of serious error conditions. Here are some of the types of DLSw events that can generate ELS messages:
Although these messages are used primarily by software engineers to resolve problems, a user with a basic knowledge of the DLSw protocol and DLC link activation flows should be able to make sense of them and debug simple configuration mistakes. By activating these ELS messages and watching the output via talk 2, you should be able to at least answer the question "Is anything happening?"
"DLS" is one of the named subsystems within ELS. To activate the standard set of error messages, type disp sub dls from the event menu under either talk 6 or talk 5. To activate all DLSw messages, enter disp sub dls all. The corresponding commands to deactivate messages begin with nodisp. For general information on controlling and viewing ELS messages, see Monitoring Event Messages.
If you are trying to trace a link activation attempt, DLSw messages alone may not show the complete picture. You can activate the ELS messages for the underlying DLC type as follows:
Refer to the Event Logging System Messages Guide (on CD-ROM and the 2216 Web Page) for a full list of individual messages and their meaning.
From a VTAM or NetView/390 operator console, you can control the links, PU, and LUs involved with DLSw as described in NetView/390.
Unlike APPN, Network Utility DLSw does not send SNA alerts. It does send traps (described in the following section) and trigger ELS messages that can generate traps. You can use the products mentioned in IBM Nways Manager for AIX to convert those traps to alerts.
Network Utility DLSw provides full read-only and partial read-write support for the IETF standard DLSw MIB documented in RFC 2024. This large MIB gives visibility to most of the important configuration, status, and accounting information that products implementing RFC 1795 and 2166 should have. This information includes:
Network Utility DLSw supports all the traps defined in RFC 2024, reporting the following events:
DLSw all supports trap control data items so a management station can set the conditions under which a trap is generated.
In addition to RFC 2024, Network Utility DLSw supports` IBM-specific DLSw MIB extensions for multicast IP-based groups and for QLLC stations.
The Network Utility Java-based application implemented in the Nways Manager products discussed in IBM Nways Manager Products provides integrated support for the standard DLSw MIB and the IBM-specific DLSw MIB extensions.
To view DLSw resources and their status using these products, you bring up specific panels that present key information from the DLSw MIB and from its underlying DLC-layer MIBs (LLC, SDLC, or X.25). You can also use integrated browser support to view the information in any of these MIBs.
You can control the emission of DLSw traps from the Nways Manager products, so that a given trap is generated always, never, or only under certain conditions.
Nways Manager for AIX can show you a DLSw topology view of your network, including DLSw connectivity, resources, and color-coded status. The topology is refreshed as new nodes are discovered. This application does not present the topology of DLSw IP multicast groups.